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METHOD AND SYSTEM FOR 
ROUTMNG SERVICE CALLS MA DE 
FROM RESOLD LINES 



BACKGROUND OF THE INVENTION 



1. Field of the Invention 

The present invention is directed to a method and system for routing telephone 
service calls, including directory information, operator-assistance, and service repair 
calls made from resold lines. More particularly, this invention is directed to a method 
and system that routes service calls from resold lines using hybrid advanced intelligent 
network and switching functionality. 



2. Background 

The current telecommunications market includes a group of incumbent local 
exchange carriers ("ILECs") that own switching infrastructures and possess intelligent 
network capabilities. Each ILEC provides local telephone service for a particular 
geographic region of the country. This group of ILECs has existed for many years, and 
only recently have smaller carriers attempted to enter the market to establish a 
foothold. To enter the market, a carrier would be required to create its own switching 
infrastructure and intelHgent network capabilities. Such a project would require the 
carrier to constmct new telephone hnes and cables, route those lines to each desired 
home, and create the necessary switching fimctionality. Clearly, this effort would cost 
millions, perhaps billions, of dollars for each emerging carrier. 

Pursuant to the Telecommunications Act of 1996, the FCC has mandated 
certain "interconnection" requirements to make it easier for new carriers to enter a 
local telecommunications market. In FCC Report & Order in the matter of Local 
Competition, docket 96-98 released August 8, 1996, the FCC required ILECs to 
"unbundle'' certain elements of their existing telecommunications network. 
"Unbundling" is a regulatory requirement providing competitive local exchange 
carriers ("CLECs") or other service providers the ability to separately lease discrete 
ftinctional components of an ILECs network to provide service. An unbundled local 
loop, for example, is an ILEC-provided transmission path between, and including, the 
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customer network interface (e.g., the jack) located at the end-customer's premises and 
the central office loop termination located in the ILEC's central office building. As 
another example, an unbundled port provides a service provider with local sv^tching 
functionality, separate from the local loop, on an ILEC's switch as an alternative to 
5 providing a stand-alone switch. Numerous components may be unbundled, including 
the local loop, switch ports, and Advanced Intelligent Network ("AIN") triggers. If 
the loop and the port are rented to a service provider, however, the entire line is 
considered "resold." 

In a resale environment, end customers on resold lines may still obtain certain 
10 services, such as operator-assisted service, directory information service ("411" and 
LNPA-555-1212, where "LNPA" is the Local Numbering Plan Area (i.e., the area 
code)), repair service ("611"), LNPA-555-1212 calls, and 976/900 number blocking, 
for example. Although the line has been resold, the customer remains connected to the 
ILEC's switch. Thus, when a resold customer dials 41 1 or 61 1, she will be connected 
15 to the ILEC's directory assistance operator or repair service operator, respectively. 
The customer v^U receive a bill from the service provider that ovms the resold line. 
This scenario is often undesirable for the service provider. The service provider would 
prefer the option of having such calls be routed to its ovm operators who can provide a 
specific type of service. 

20 To allow service providers to select their own locations for handling service 

calls, certain LLECs have incorporated methods within their network to identify 
individual lines as being resold. The use of line class codes is one such method for 
identifying resold lines. A line class code is a code v^thin the ILEC's end office switch 
that is used to index a routing profile for a particular class of service. Each class of 

25 service, including various configurations of residential and business services, is 
assigned a line class code. The switch uses the line class code to determine the proper 
routing for the call. Each time a new service provider is introduced, a new set of line 
class codes corresponding to the existing line class codes may be assigned. This 
solution is not entirely feasible because a new line class code must be assigned 

30 potentially for every class of service and for every carrier. Moreover, the line class 
codes must be replicated in every switch. While ILECs have taken measures to 
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prevent running out of line class codes, these codes are still considered limited 
resources. 

Alternatively, DLECs may add new software directly to the switch to determine 
the proper routing for service calls made on resold lines. This would require modifying 
each switch in the ILEC's network. Switch vendors, however, have indicated that the 
capability to implement such modifications is years away and would be prohibitively 
expensive. In addition, making routing modifications in every switch would be very 
time-consuming. 

The use of a pure advanced intelligent network ("AIN") method is a third 
option for ELECs. In an AIN environment, network nodes work autonomously and 
make decisions on routing and call handling without human intervention. Databases 
are often used to store information on how certain calls should be routed, or how calls 
should be handled. AIN triggers are also used to instruct various nodes on where to 
route calls and/or how to handle such calls. Unfortunately, the pure AIN solution has 
drawbacks. First, all of the ILEC's sv^tches may not be AIN-compatible, thus making 
a complete AIN solution impossible. Second, all calls do not automatically cause an 
AIN trigger to fire. Thus, certain nodes would not detect certain calls as having been 
made from a resold line. As a result, such call would not be properly routed to the 
service provider's desired location. 

SUMMARY OF THE INVENTION 

The present invention overcomes the problems of the prior art by providing a 
hybrid AIN/switching solution. More particularly, the method and system of this 
invention allows service providers to route service calls to predetermined service 
locations from lines that are coupled to AIN or non-AIN switches. All calls are routed 
to a central AIN hub, such as a service switching point. The AIN hub transmits a 
query to a service control point that accesses a database to provide routing instructions 
for the hub. The AIN hub then routes the call to the predetermined service location. 

Service calls may be made firom resold lines terminating at AIN or non-AIN 
switches. The switch uses line class code tables to determine the proper routing for 
the service call. Rather than use multiple sets of line class codes for each service 
provider, however, this invention uses a single set of line class codes, for all resold 
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lines. The line class codes for resold lines reference the AIN hub. Unlike previous 
methods, valuable storage space and memory within the switch are not consumed by 
the addition of resold lines. Instead,j[esold lines are all assigned the single set of line 
class codes that reference a trunk group to the AIN hub. Thus, this invention is a more 
efficient alternative for service providers. 

The AIN hub may be an AIN-capable switch, such as a service switching point. 
The hub is provisioned with a call origination AIN trigger, such as, for example, an 
off-hook delayed trigger. The trigger is assigned to the incoming trunk groups from 
the end office switches. The call origination trigger assigned to the trunk groups 
causes the hub to suspend each incoming call and query a service control point for 
routing instructions. The use of a centralized AIN hub also removes the burden of 
routing calls from the end office switches. Since all calls are ultimately routed to the 
hub, these end offices simply perform the line class code search and route all calls from 
resold lines to the hub. 

The AIN hub transmits a query to a service control point. The query includes 
the directory number of the resold line and the dialed number. The service control 
point receives the query and accesses one or more databases to determine the routing 
information for handling the call as specified by the service provider. The database 
includes at least two tables. The first table matches the directory number of the resold 
line to the service provider that owns the line. The service provider may be identified 
by name or number. Once the service provider is identified, the service control point 
searches additional tables to determine the routing information. These tables may 
include routing information for each type of service call for each carrier and, possibly, 
based on the caller's location. Once the routing information is obtained, the service 
control point sends the routing information back to the AIN hub. 

The AIN hub receives the routing information from the service control point 
and routes the service call as specified. The carrier may then handle the call in the 
appropriate manner. 

As additional service providers are added, the system may be easily configured 
or reconfigured. Once the line is identified as a resold line, the set of line class codes 
for resold lines will cause the switch to route all service calls from the resold line to the 
AIN hub. The service provider can specify various locations for handling different 
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types of service calls. These locations are stored in the service control point which will 
return the proper routing information to the AIN hub. The AIN hub will then route 
the service call to the specified location. Unlike the prior art scenario, each switch 
does have to be reconfigured. 

Generally described, this invention is a system for routing a service call made 
from a resold calling line. The system includes a switch coupled to the line, the switch 
being operative to route the service call to a trunk group; a service switching point 
coupled to the trunk group, the switch having a trigger provisioned thereon to cause 
the switch to launch a query to a service control point upon receiving the call fi-om the 
trunk group; and a service control point operative to receive the query fi-om the service 
switching point and to provide routing instructions to the service switching point based 
upon routing information stored in at least one database coupled to the service control 
point, the routing information specifying instructions for handling the service call. 

In another embodiment of this invention, a method for routing a service call 
made from a resold calling line includes the steps of: routing the service call to a 
switch; routing the service call firom the switch to a trunk group; routing the service 
call from the trunk group to a service switching point; transmitting a query from the 
service switching point to the service control point to determine a location for handling 
the service call, the query including a directory number of the calling line and a called 
number; accessing a database containing an identifier for the service provider and 
instructions for handling the service call; transmitting the instructions to the service 
switching point; and routing the call from the service switching point to the location 
for handling the service call. 

Accordingly, it is an object of this invention to provide a system for routing 
service calls made from lines resold to competitive service providers. 

It is a fiirther object of this invention to provide a system for routing service 
calls made from resold lines coupled to advanced intelligent network switches. 

It is yet another object of this invention to provide a system for routing service 
calls made from resold lines coupled to non-advanced intelligent network sv^tches. 

It is an additional object of this invention to provide a system for routing 
service calls that eliminates the need for multiple line class codes for each carrier and 
each type of service. 
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It is a further object of this invention to provide a system for routing service 
calls that allows a service provider to specify the location for handling the service call. 

It is an additional object of this invention to provide a system for routing 
service calls that allows a service provider to specify multiple locations for handling 
various types of service calls. 

It is an additional object of this invention to provide a system for routing 
service calls that includes a central hub, thus making it easier to configure and 
reconfigure network elements when service providers and classes of service are added. 

It is a further object of this invention to provide a system for routing service 
calls that incorporates AIN solutions to make call routing more flexible than non-AIN 
solutions. 

Additional objects and advantages of the invention will be set forth in part in 
the description which follows and in part will be obvious from the description or may 
be learned by practice of the invention. The objects and advantages of the invention 
will be realized and attained by means of the elements and combinations particularly 
pointed out in the appended claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIGURE 1 is a block diagram of an ILEC telephone network 30, according to 
a preferred embodiment of the present invention. 

FIGURE 2 is an example of a prior art line class code/screening index table as 
stored in a database. 

FIGURE 3 is a line class code table, according to a preferred embodiment of 
the present invention. 

FIGURE 4 is a block diagram of a Calling Party Number-to-Carrier Table 
stored in a Line/Carrier database. 

FIGURE 5 is a block diagram of a Carrier Routing table as stored in the 
Line/Carrier database. 

FIGURE 6 is a block diagram of a network illustrating the method and system 
of this invention. 

FIGURE 7 is an illustration of an exemplary Calling Party Number-to-Carrier 
table in Line/Carrier database. 
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FIGURE 8 is an illustration of an exemplary Carrier Routing Table, 
FIGURE 9 is a flow chart illustrating the steps performed using the method and 
system of this invention, 

DETAILED DESCRIPTION 

Reference will now be made in detail to the invention, examples of which are 
illustrated in the accompanying drawings. Wherever possible, the same reference 
numbers will be used throughout the drawings to refer to the same or like parts. 

FIGURE 1 is a block diagram of an ILEC telephone network 30, according to 
a preferred embodiment of the present invention. The network 30 includes a plurality 
of telephone lines 40-48 coupling terminating equipment, such as, for example, a group 
of telephones 50-58 to one or more end offices 60-64. Although telephones are 
illustrated as the terminating equipment in FIGURE 1, those skilled in the art will 
understand that such terminating equipment may include other telecommunication 
devices including, but not limited to, facsimile machines, computers, modems, etc. 
Certain of the telephone lines 40-46 are lines that have been resold by the ILEC to one 
or more competitive service providers. The resold lines 40-46 may be for 
home/personal use or for business/commercial use Each of the resold lines 40-42 may 
include one or more services offered by the service provider, including, but not limited 
to 411 directory assistance, 611 emergency repair, LNPA-555-1212, operator-assisted 
calls, and the blocking of 976 and/or 900 numbers. Each resold line allows a calling 
party (not shown) to dial a called party or a service number. In this exemplary 
embodiment the service provider has designated one or more operation services center 
150 for accepting service calls from resold lines. It should be apparent that the service 
provider may designate multiple services centers for handling various types of service 
calls. 

The resold lines extend from the called party's residence or business to end 
offices 60-64 operated by the ILEC. The end offices 60-64 connect subscribers in the 
network to each other and to other end offices via a trunk group. The end offices 
include serving svsntches that allow calls to be switched to and from other calling areas. 
End office 60 is an AIN-end office, such as a service switching point ("SSP"). An SSP 
typically includes switch functionality, but also includes other functionality so as to 
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communicate with other ATN elements as those skilled in the art understand. End 
offices 62-64 are non-AIN end offices: The end offices in FIGURE 1 are illustrated 
for exemplary purposes only. This invention may be used for resold lines coupled to 
either AIN end offices or non-AIN end offices. The network 30 may include 
additional elements, such as signal transfer points (not shown) that route calls between 
SSPs and other network elements. For further information regarding AIN technology 
and aspects thereof, the interested reader is referred to U.S. Patent No. 5,430,719, to 
Weisser, which is incorporated herein by reference. 

End offices 60-64 include line class code ("LCC") tables 160-164, respectively, 
that contain line class codes and screening indices for various classes of services. 
FIGURE 2 is an example of a prior art Hne class code table 220 as stored in an end 
office. Each line owned by the ELEC is assigned a particular line class code depending 
upon the service provider owning the line and the class of service available for that 
line. As shown, the table 220 includes a line class code column 230, and a plurality of 
service columns 240-260 for various types of service. In the exemplary table 220, line 
class codes 110, 112, 113, and 1 14 are codes for ILEC-owned lines. Line class codes 
210, 212, 213, and 214 are assigned to lines owned by another service provider (e.g., 
"Service Provider 2"). Line class codes 310, 312, 313, and 314 are assigned to lines 
owned by a third service provider (e.g., "Service Provider 3"). The service columns 
specify whether the class of service for the particular line class code includes a 
particular service. The routing information column 270 then specifies the routing 
information for that class of service. For example, the table 220 indicates that the 
ELEC-owned lines having line class code 110 may make operator-assisted calls, 411 
calls, and 611 calls. ILEC-owned lines having line class code 112 may only make 
operator-assisted service calls and 411 calls. Similarly, the lines owned by the other 
service providers having line class code 210 and 310 may make all three types of calls. 
As new service providers are added, the entire set of service classes must be replicated 
and a new set of line class codes must be assigned for the replicated service class. In 
the table 220, for example, lines having line class codes 10, 110, and 210 share the 
same type of service, yet each line has different line class codes. 

FIGURE 3 is a screening index table 300, according to this invention. All 
resold lines are assigned one new set of line class codes without regard to the service 
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provider. The table 300 thus includes a Une class code column 310 containing the class 
code for a line. Line class codes 1 10, 112, 113, and 114 are ILEC line class codes,. 
Line class codes 210, 212, 213, and 214 are resold line class codes. Service columns 
320-340 identify particular types of service that the line may or may not include. The 
routing information column 350 contains routing information for each line class code 
and class of service. In the present invention, the routing information for all resold line 
class codes specifies that the service call be routed to an AESf hub. 

In this invention, all service calls made from resold lines are routed to an AIN 
hub 190 (FIGURE 1). Calls may be routed using a routing index in the line class 
code table. The trunk groups terminate on ports in an AESf hub element 190. The 
AIN hub 190 is an AIN-capable end office, such as a service switching point. Any 
AIN-capable switch in the network may be designated the AIN hub 190. Although 
one AIN hub 190 is illustrated in FIGURE 1, a network may contain numerous AIN 
hubs. 

To notify the AIN hub 190 that AIN functions must be invoked (i.e., a query to 
a Service Control Point), the trunk groups 173, 177, 179 terminating at the AIN hub 
190 are each assigned an oflF-hook delayed ("OHD") AIN trigger 187. Triggers are 
assigned on a per-trunk basis. The OHD trigger is normally associated with individual 
subscriber lines, rather than inter-switch trunk connections, as used in the present 
invention. When used with individual subscriber lines, the switch assigned to the line 
recognizes an OHD trigger upon receiving a valid number sequence following an off 
hook condition. The use of an OHD trigger in connection with inter-switch trunk 
connections, however, causes the AIN hub 190 to suspend all calls from that trunk 
group and launch a query to an SCP. Since the trunk group is designated specifically 
for routing service calls pursuant to this invention, the use of the OHD trigger in this 
manner is not cumbersome.. 

In response to the OHD trigger, the AIN hub 190 suspends the call and 
launches a query to an AIN Service Control Point ("AIN SCP") 200. As part of the 
query, the AIN hub 190 provides the AIN SCP 200 with the calling number of the 
calling party and the service number dialed by the calling party. The AIN SCP 200 is a 
computer server that accesses one or more databases and returns information to other 
network components based on service-specific programming. The SCP 200 receives 
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call information in a query from the AIN hub 190 and translates query information 
(i.e., the calling number and dialed number) into routing instructions for the AIN hub 
190. In this invention, AIN SCP 200 accesses a Line/Carrier database 220 containing 
information regarding the calling party's carrier and call type. 

The Line/Carrier database stores several accessible tables, including a Calling 
Party Number-to-Carrier Table 400. FIGURE 4 is an illustration of an exemplary 
Calling Party Number-to-Carrier Table 400 stored in Line/Carrier database 220. The 
table 400 includes a Calling Party Directory Number column 420 containing a Ust of 
Calling Party numbers for resold lines, and a Local Exchange Carrier column 440 
containing local exchange carrier identifiers corresponding to each calling party 
number. The local exchange carrier may be identified by name, number, or any other 
method for identifying a carrier. The AIN SCP 200 accesses the database 220 and 
searches the Calling Party Number-to-Carrier Table 400 for the calling party number 
provided by the AIN hub 190. Upon finding the calling party number in the Calling 
Party Number column 420, the AIN SCP 220 references the corresponding Local 
Exchange Carrier identifier in the Local Exchange Carrier column 440. 

The AIN SCP 200 then uses the local exchange carrier identifier to access a 
Carrier Routing table 500 stored in the Line/Carrier database 220. FIGURE 5 is a 
block diagram of an exemplary Carrier Routing table 500 as stored in the Line/Carrier 
database 220. The Carrier Routing table 500 includes a Local Exchange Carrier 
Identifier column 520, and a plurality of call type columns 530, 540, 550. The Local 
Exchange Carrier column 520 stores a plurality of identifiers for various local 
exchange carriers. The identifiers correspond to the identifiers found in the Local 
Exchange Carrier colunm 440 of the Calling Party Number-to-Carrier Table 400. 
Thus, the AIN SCP 200 uses the identifier obtained from the Calling Party Number-to- 
Carrier Table 400 to locate the carrier in the Carrier Routing table 500. Each local 
exchange carrier may desire that calls be routed to different locations within the 
network (or to other networks) depending upon the type of service call. Accordingly, 
once the AIN SCP 200 finds the appropriate local exchange carrier identifier, it also 
locates the appropriate Call Type column depending upon the call type. For instance, 
in FIGURE 5, call type #1 may correspond to 411 calls, call type #2 may correspond 
to 611 calls, call type #3 may correspond to operator-assisted calls, etc. It should be 
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apparent, however, that other service calls and non-service calls may be handled using 
a similar table. Once the correct carrier and call type have been located, the routing 
information may be obtained from that entry. The routing information may be any 
known type of routing information, including a routing index, a directory number, a 
carrier code or any combination of these. Other tabular information in the SCP may be 
used to make additional routing decisions based on, for example, the area in which the 
caller is located. 

The AJN SCP 200 transmits the original calling number, the routing 
information, the dialed number, and the local exchange carrier identifier to the AIN 
hub 190. The routing index points to a set of trunks specified by the local exchange 
carrier in the Carrier Routing table. The AIN hub 190 transmits, as supported by the 
trunk type, the calling number, the dialed number, and the local exchange carrier 
identifier to the trunk group designated by the routing information. The call may then 
be handled by the service provider as it chooses. 

With continuing reference to FIGURES 1-5, and now turning to FIGURE 6, 
the exemplary operation of this invention is described in the context of a subscriber to 
a competitive service provider placing a service call to "41 1" directory information. It 
will be appreciated by one skilled in the art that this invention is not limited to use of 
"411" calls, but may also include other service calls, including, but not limited to 
operator assistance calls, telephone repair calls, and collect calls. 

In this example, a calling party ("Joe") having a calling party number (770-555- 
1234) uses his telephone 602, which is connected by calling line 604 to end office 610, 
In this example, end office 610 is an AIN-capable end office (i.e., an SSP). Joe places 
a call to "411" directory information. Joe subscribes to a competitive service provider 
("CLEC 1"). CLEC 1, which is identified in the network by the identifier "604", has 
requested that all directory information calls be routed to a directory information 
service center 640 within the network. The service center 640 has a routing index 
number of "RI209". The ILEC, by arrangement, has stored the routing index for the 
information service center 640 within its AIN SCP databases. 

As a result of Joe dialing "411", the SSP 610 accesses a line class code table 
614. Within the table, the calling line is identified as a resold line of a particular class. 
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The table 614 includes a routing index (or other routing identifier) for an AIN hub 650 
within the network. The SSP 610 then routes the call to the AIN hub 650. 

An OHD trigger assigned to the trunk group terminating at the AIN hub causes 
the AIN hub 650 to suspend the incoming call and query an SCP 670. The AIN hub 
650 transmits a query to the SCP 670 containing the calling party number (770-555- 
1234) and the originally dialed number ("411"). The SCP 670 accesses a database 675 
to determine where the call should be routed. 

FIGURE 7 is an illustration of an exemplary Calling Party Number-to-Carrier 
table 700 in Line/Carrier database 675. As shown, Joe's number is hsted among the 
various calling party numbers in the Calling Party Number column 720. The Local 
Exchange Column 720 Carrier lists "604," the identifier for CLEC 1, as Joe's carrier. 

Once CLEC 1 is identified as the carrier for Joe, the SCP searches the Carrier 
Routing Table in the database 675. The SCP 670 uses the carrier identifier obtained 
from the Calling Party Number-to-Carrier table 700 to obtain the routing instructions. 
FIGURE 8 is an illustration of an exemplary Carrier Routing Table 800. As illustrated, 
the carrier, CLEC 1, has routing instructions for operated-assisted, 411, and 611 calls. 
The SCP 670 finds the service provider identifier in the table 800. Next, the SCP 670 
obtains the routing instructions for 411 calls for subscribers of that carrier. As show, 
the carrier has specified that 411 calls be routed to routing index number RI209~the 
routing index number for the service center 640. Accordingly, the SCP 670 transmits 
the routing index number back to the SSP 610. 

The SSP 610 routes the call to the routing index specified by the SCP 670. 
The call is then connected to the carrier's service center 640, 

Certain service providers may want the ELEC to continue providing operator 
services for "0" calls. In these cases, the service provider will want the ILEC to 
provide "branding" services, whereby the ILEC plays a recording identifying the 
service provider prior to handling the call and upon concluding the call. Branding may 
be accomplished by implementing a method for screening the originating line number in 
the operator services switches. Calls are routed to the ILEC's operator services 
switch. The SAvitch will send a query to determine the service provider. Once the local 
service provider is identified, the operator services switch will play the correct 
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branding announcement, process the call, and then play a final branding announcement 
before releasing the call, 

FIGURE 9 is a flow chart illustrating the flow of information during a call from 
a caller on a non-AIN resold line to a local operator (a "0" call). In step 902, the caller 
5 dials "0". In step 904, the serving switch in the non-AIN end office accesses a line 
class code to correlate the line class code of the caller's calling line to the appropriate 
routing identifier. Accordingly, in step 906, the serving switch determines that the line 
class code table identifies this line as a resold line and for "0" calls, the call should be 
routed to the AIN hub. 

10 In step 908, the call is routed to the AIN hub via a trunk group terminating at a 

port in the AIN hub. The trunk group, however, has been assigned an AIN off-hook 
delayed trigger. Thus, in step 910, the AIN hub will suspend the call, collect all of the 
digits in the call and immediately launch a query to the AIN SCP. The query will 
include the calling number of the caller and the originally dialed number ("0"). The 
15 AIN SCP launches a service package to determine where this call should be routed. 
First, in step 912, the AIM SCP determines the local exchange carrier for the caller 
based upon the calling mamber. More particularly, the AIN SCP accesses the Calling 
Party Number-to-Carrier Table in the Line/Carrier database. The AIN SCP obtains a 
local exchange carrier code. The AIN SCP then accesses the Carrier Routing table. 
20 The AIN SCP obtains the appropriate routing information for the specified exchange 
carrier code and dialed number in step 914. In step 916, the AIN SCP provides the 
routing information, the calling number, and the carrier code back to the AIN hub. In 
step 918, the AIN hub routes the call to the location specified by the AIN SCP using 
the provided routing instructions, 
25 Having thus described a method and system for routing service calls made from 

resold lines, it should be apparent to those skilled in the art that certain advantages 
have been achieved. It should also be appreciated that various modifications, 
adaptations, and alternative embodiments thereof, including the use of multiple AIN 
hubs and additional SCPs and SCP databases, for example, may be made within the 
30 scope and spirit of the present invention. The invention is further defined by the 
following claims: 
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